Cluster manuell erstellen (aus Single-Server-Installation)

Manchmal ist es der Fall, dass eine Single-Server-Installation, bei der alle IQ4docs Komponenten auf einem Rechner installiert sind, zu einem Clusterverbund erweitert werden soll. Im Folgenden sprechen wir von dieser Installation als erster Clusterknoten (server1).

Für eine Ausfallsicherheit sollten MongoDB und RabbitMQ auf mindestens 3 Servern installiert werden. Hierbei ist es zwingend erforderlich eine ungerade Anzahl an Servern zu verwenden - mehr als 3 Server sind nicht unbedingt erforderlich, steigern aber bis zu einem gewissen Grad die Gesamtleistung. Bei einer geraden Anzahl an Servern kann bei einer Verbindungsunterbrechung nicht in jedem Fall gewährleistet werden, dass die verbleibenden Teile aufgrund einer Mehrheit an Knoten entscheiden können, ob die Rolle des primären Knotens delegiert werden kann. Dies erfordert dann einen manuellen Eingriff und widerspricht dem Gesamtkonzept.

Das Tool muss immer auf dem Server ausgeführt werden, welcher dem Cluster hinzugefügt werden soll.

Nehmen Sie auf den Servern, welche das System zum Cluster erweitern sollen (server2 und server3), die Installation des IQ4docs vor (falls auf diesen Rechnern bereits eine RabbitMQ- oder MongoDB-Installation war, entfernen Sie vor der Installation alle Reste dieser Installationen (Verzeichnisse, .erlang.cookies...).

Stellen Sie nun einen Clusterverbund der neuen RabbitMQ-Installationen mit dem ersten Clusterknoten her.

Wiederholen Sie die folgenden Schritte für die weiteren Clusterknoten (mindestens server3).

Bei einer Single Server Installation wird immer der gleiche .erlang.cookie erstellt, dieser Schritt ist also nur bei einem im Installer definierten Cookie notwendig.

Nur wenn die .erlang.cookies übereinstimmen, dürfen RabbitMQ-Nodes miteinander kommunizieren.

  • Kopieren Sie dazu vom ersten Clusterknoten den .erlang.cookie (z.B. C:\Users\Administrator\.erlang.cookie) und ersetzen Sie auf server2 alle .erlang.cookies durch den des ersten Clusterknotens. Diese sind zu finden in:
    • Systemprofil-Verzeichnis (z.B. c:\windows\System32\config\systemprofile)
    • Anwenderverzeichnis des Installierenden Anwenders (z.B. C:\Users\Administrator)
  • Starten Sie Server2 anschließend neu.

Ob der verwendete .erlang.cookie gleich ist, kann im Log der RabbitMQ (IQ4docs-Installationsverzeichnis\RabbitMQ\RabbitMQ\Logs) unter dem Eintrag cookie hash verglichen werden.

Öffnen Sie nun auf server2 eine Kommandozeile mit Administratorrechten.

Wechseln Sie in das Cluster-Verzeichnis der RabbitMQ-Installation (<Installationspfad>\RabbitMQ\Cluster).

Verbinden Sie nun die RabbitMQ-Installation auf server2 mit dem ersten Clusterknoten mittels Kommandozeilen Befehl RabbitMqCluster -c Add -h Server2 -r Server1 -d "<Installationspfad>\RabbitMQ\RabbitMQ\sbin".

Der Befehl RabbitMqCluster --help gibt Aufschluss über die möglichen Funktionen und weitere Befehle.

Es erscheint etwas wie:

stopping rabbit application on node rabbit@server2 ...

joining cluster rabbit@server1

Clustering node rabbit@server2 with rabbit@server1 ...

[...]

restart RabbitMQ service

applying policy for HA-mode

Um zu überprüfen, ob der Clusterverbund erfolgreich war, melden Sie sich von einem der verbunden Server an die RabbitMQ an.

  • Öffnen Sie dazu im Browser die URL http://localhost:15672 und melden sich an (Standardwerte: Benutzername: admin und Passwort: admin).
  • In der Übersicht werden die Knoten angezeigt (dies kann einige Zeit dauern). Falls diese dauerhaft als Node not running angezeigt werden, starten Sie den Dienst der auf server2 und server3 neu.

Damit die Daten der RabbitMQ hochverfügbar werden, müssen Sie zwischen den Clusterknoten synchronisiert werden. Dazu wird der ha-mode (highly available mode) aktiviert und auf alle Queues der Services angewendet. Temporäre Queues und DeviceGui-Queues werden nicht synchronisiert und erhalten eine andere Policy.

  • Öffnen Sie zum Anlegen der Policies im Browser die URL http://localhost:15672 und melden sich an (Standardwerte: Benutzername: admin und Passwort: admin).
  • Öffnen Sie den Bereich Admin und klicken dort auf der rechten Seite auf Policies.
  • Legen Sie die nachstehenden 3 Policies an.
Name Pattern Apply to Definition Priority
HA-TWO service.* queues ha-mode: exactly (String)
ha-params: 2 (Number)
ha-sync-mode: automatic (String) 		5
DeviceGui ^deviceservice.deviceclient.gui\. queues message-ttl: 5000 (Number) 10
TempQueues [0-9a-fA-F]{8}-  queues message-ttl: 5000 (Number)
expires: 120000 (Number) 		10

Im Bild ist beispielhaft das Anlegen der HA-TWO Policy dargestellt.

Nach Anlage der Policies werden diese in Tabellenform dargestellt.

Geben Sie die Policies ganz genau so an, wie in der Tabelle angegeben. Eine Abweichung von nur einem Zeichen kann die Funktion beeinträchtigen.

Bei den Queues ist unter Features jetzt zu sehen, welcher Policy sie unterliegen.

Die folgenden Schritte müssen für alle weiteren neuen Server wiederholt werden (mindestens Server3).

Stoppen Sie auf Server2 den MongoDB Dienst in den Windows Diensten.

Löschen Sie den Inhalt des Datenbankverzeichnis der MongoDB im <Installationsverzeichnis>\MongoDB\Data\db.

Öffnen Sie nun auf server2 eine Kommandozeile mit Administratorrechten.

Wechseln Sie in das Cluster-Verzeichnis der MongoDB-Installation (<Installationspfad>\MongoDB\Cluster).

Verbinden Sie nun die MongoDB-Installation auf server2 mit dem ersten Clusterknoten Server1 mittels Kommandozeilen Befehl MongoDBCluster -c Add -h Server2 -r Server1 -d "<Installationspfad>\MongoDB".

Der Befehl MongoDBCluster --help gibt Aufschluss über die möglichen Funktionen und weitere Befehle.

Die MongoDB bestimmt selbstständig, welcher Knoten PRIMARY und welche SECONDARY sind (es existiert bei der MongoDB keinen "Master"-Clusterknoten).

Wenn der Fehler not enough voting nodes responded. Failed with Received heartbeat auftaucht, dann wurde der db-Inhalt nicht gelöscht. In unserem Installer wird ein rs.initiate() Befehl ausgeführt, welcher das clustern der db´s untereinander verhindert.

Es erscheint etwas wie:

mongodb config is already modified

stopping IQ4docsMongoDB

starting IQ4docsMongoDB

rs.status is :

{

"set" : "Workflow",

"date" : ISODate("2017-11-06T12:46:14.861Z"),

"myState" : 1,

"term" : NumberLong(1),

"heartbeatIntervalMillis" : NumberLong(2000),

"members" : [

{

"_id" : 0,

"name" : "server1:27017",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 6123,

"optime" : {

"ts" : Timestamp(1509966526, 1),

"t" : NumberLong(1)

},

"optimeDate" : ISODate("2017-11-06T11:08:46Z"),

"electionTime" : Timestamp(1509966314, 2),

"electionDate" : ISODate("2017-11-06T11:05:14Z"),

"configVersion" : 3,

"self" : true

},

{

"_id" : 1,

"name" : "server2:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 5936,

"optime" : {

"ts" : Timestamp(1509966526, 1),

"t" : NumberLong(1)

},

"optimeDate" : ISODate("2017-11-06T11:08:46Z"),

"lastHeartbeat" : ISODate("2017-11-06T12:46:13.691Z"),

"lastHeartbeatRecv" : ISODate("2017-11-06T12:46:14.150Z"),

"pingMs" : NumberLong(0),

"syncingTo" : "W2012DEV4:27017",

"configVersion" : 3

},

{

"_id" : 2,

"name" : "server3:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 5847,

"optime" : {

"ts" : Timestamp(1509966526, 1),

"t" : NumberLong(1)

},

"optimeDate" : ISODate("2017-11-06T11:08:46Z"),

"lastHeartbeat" : ISODate("2017-11-06T12:46:14.578Z"),

"lastHeartbeatRecv" : ISODate("2017-11-06T12:46:10.127Z"),

"pingMs" : NumberLong(0),

"configVersion" : 3

}

],

"ok" : 1

}

Nehmen Sie auf den Servern, welche das System zum Cluster erweitern sollen (server2 und server3), die Installation des IQ4docs vor (falls auf diesen Rechnern bereits eine RabbitMQ- oder MongoDB-Installation war, entfernen Sie vor der Installation alle Reste dieser Installationen (Verzeichnisse, .erlang.cookies...).

Stellen Sie nun einen Clusterverbund der neuen RabbitMQ-Installationen mit dem ersten Clusterknoten her.

Wiederholen Sie die folgenden Schritte für die weiteren Clusterknoten (mindestens server3).

Bei einer Single Server Installation wird immer der gleiche .erlang.cookie erstellt, dieser Schritt ist also nur bei einem im Installer definierten Cookie notwendig.

Nur wenn die .erlang.cookies übereinstimmen, dürfen RabbitMQ-Nodes miteinander kommunizieren.

  • Kopieren Sie dazu vom ersten Clusterknoten den .erlang.cookie (z.B. C:\Users\Administrator\.erlang.cookie) und ersetzen Sie auf server2 alle .erlang.cookies durch den des ersten Clusterknotens. Diese sind zu finden in:
    • Systemprofil-Verzeichnis (z.B. c:\windows\System32\config\systemprofile)
    • Anwenderverzeichnis des installierenden Anwenders (z.B. C:\Users\Administrator)
  • Starten Sie Server2 anschließend neu.

der verwendete .erlang.cookie kann im Log der RabbitMQ (IQ4docs-Installationsverzeichnis\RabbitMQ\RabbitMQ\Logs) unter dem Eintrag cookie hash verglichen werden.

Öffnen Sie nun auf server2 eine Kommandozeile mit Administratorrechten.

Wechseln Sie in das sbin-Verzeichnis der RabbitMQ-Installation (<Installationspfad>\RabbitMQ\RabbitMQ\sbin).

Stoppen Sie die RabbitMQ-Applikation (RabbitMQ-Dienst muss weiter laufen):

  • rabbitmqctl.bat stop_app

Es erscheint etwas wie: Stopping rabbit application on node rabbit@server2 ...

Falls hier ein Fehler auftritt, könnte es daran liegen, dass das HOMEDRIVE nicht gefunden wird. Setzen Sie in diesem Fall das HOMEDRIVE manuell auf c: (set HOMEDRIVE=c:).

Verbinden Sie nun die RabbitMQ-Installation auf server2 mittels rabbitmqctl.bat join_cluster rabbit@<Hostname erster Clusterknoten> mit dem ersten Clusterknoten. Achten Sie darauf, dass der Hostname - auch in Groß- und Kleinschreibung - genau übereinstimmt und dieser Name aufgelöst werden kann.

Das Kommando rabbitmqctl join_cluster verwendet standardmäßig den Shortname des Hostnames. Beim FQDN muss der Parameter --Longnames vorab mitgegeben werden (Befehlssyntax: rabbitmqctl [--node <node>] [--longnames] [--quiet] join_cluster).

  • rabbitmqctl.bat join_cluster rabbit@server1
  • oder rabbitmqctl.bat --longnames join_cluster rabbit@server1.hostname1.local

Es erscheint etwas wie: Clustering node rabbit@server2 with rabbit@server1 ...

Starten Sie die RabbitMQ-Applikation wieder:

  • rabbitmqctl.bat start_app

Es erscheint etwas wie: Starting node rabbit@server2 ...

Wenn beim Starten der Applikation ein Fehler auftritt, den RabbitMQ Dienst neu starten und diesen Schritt erneut durchführen.

Um zu überprüfen, ob der Clusterverbund erfolgreich war, melden Sie sich von einem der verbunden Server an die RabbitMQ an.

  • Öffnen Sie dazu im Browser die URL http://localhost:15672 und melden sich an (Standardwerte: Benutzername: admin und Passwort: admin).
  • In der Übersicht werden die Knoten angezeigt (dies kann einige Zeit dauern). Falls diese dauerhaft als Node not running angezeigt werden, starten Sie den Dienst der auf server2 und server3 neu.

Damit die Daten der RabbitMQ hochverfügbar werden, müssen Sie zwischen den Clusterknoten synchronisiert werden. Dazu wird der ha-mode (highly available mode) aktiviert und auf alle Queues der Services angewendet. Temporäre Queues und DeviceGui-Queues werden nicht synchronisiert und erhalten eine andere Policy.

  • Öffnen Sie zum Anlegen der Policies im Browser die URL http://localhost:15672 und melden sich an (Standardwerte: Benutzername: admin und Passwort: admin).
  • Öffnen Sie den Bereich Admin und klicken dort auf der rechten Seite auf Policies.
  • Legen Sie die nachstehenden 3 Policies an.
Name Pattern Apply to Definition Priority
HA-TWO service.* queues ha-mode: exactly (String)
ha-params: 2 (Number)
ha-sync-mode: automatic (String) 		5
DeviceGui ^deviceservice.deviceclient.gui\. queues message-ttl: 5000 (Number) 10
TempQueues [0-9a-fA-F]{8}-  queues message-ttl: 5000 (Number)
expires: 120000 (Number) 		10

Im Bild ist beispielhaft das Anlegen der HA-TWO Policy dargestellt.

Nach Anlage der Policies werden diese in Tabellenform dargestellt.

Geben Sie die Policies ganz genau so an, wie in der Tabelle angegeben. Eine Abweichung von nur einem Zeichen kann die Funktion beeinträchtigen.

Bei den Queues ist unter Features jetzt zu sehen, welcher Policy sie unterliegen.

Die folgenden Schritte müssen auf allen Servern durchgeführt werden (server1, server2 und server3).

In der Konfiguration der MongoDB muss die Datenbank, die repliziert werden soll (Workflow) angegeben werden.

Fügen Sie am Ende der Konfigurationsdatei mongod.cfg (im Verzeichnis <Installationspfad>\MongoDB) folgende Zeilen ein:

replication:

replSetName: "Workflow"

Die mongod.cfg darf keine Leerzeilen oder TABs enthalten (außer ganz am Ende).

Damit die bisher vorgenommenen Einstellungen greifen, müssen die MongoDB-Dienste neu gestartet werden. Starten Sie den ersten Clusterknoten (server1) zuerst und dann server2 und server3.

Auf dem primären Clusterknoten (nicht auf allen Servern!) kann jetzt der Clusterverbund hergestellt werden. Dies ist abhängig von der Startreihenfolge der MongoDB-Dienste in diesem Fall server1. Dieser Server meldet sich in der Mongo-Shell mit Workflow:PRIMARY>.

Öffnen Sie nun auf server1 eine Kommandozeile mit Administratorrechten.

Wechseln Sie in das bin-Verzeichnis der MongoDB-Installation (<Installationspfad>\MongoDB\bin).

Fügen Sie jetzt die server2 und server3 dem ReplicaSet (rs) hinzu. Geben Sie dazu folgende Zeilen ein (und bestätigen diese jeweils mit Enter).

Verbinden Sie sich mit der Workflow-Datenbank:

  • mongo Workflow

Es erscheint etwas wie :

MongoDB shell version: v3.6.3
connecting to: mongodb://127.0.0.1:27017/Workflow

...
>

ReplicaSet initialisieren:

  • rs.initiate()

Es erscheint etwas wie:

{
"info2" : "no configuration specified. Using a default configuration for the set",
"me" : "server1:27017",
"ok" : 1
....

Clusterknoten hinzufügen:

  • rs.add("server2:27017")
  • rs.add("server3:27017")

Verwenden Sie anstatt server2 und server3 die beiden Rechner, auf denen nur RabbitMQ und MongoDB installiert wurden. Es erscheint jeweils etwas wie:

{ "ok" : 1 }

Sie können den Verbund prüfen, indem Sie den Status abrufen. Ein Clusterknoten muss dabei mit PRIMARY gekennzeichnet sein, die anderen Clusterknoten mit SECONDARY.

Die MongoDB bestimmt selbstständig, welcher Knoten PRIMARY und welche SECONDARY sind (es existiert bei der MongoDB keinen "Master"-Clusterknoten).

  • rs.status()

Es erscheint etwas wie:

{

"set" : "Workflow",

"date" : ISODate("2017-11-06T12:46:14.861Z"),

"myState" : 1,

"term" : NumberLong(1),

"heartbeatIntervalMillis" : NumberLong(2000),

"members" : [

{

"_id" : 0,

"name" : "server1:27017",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 6123,

"optime" : {

"ts" : Timestamp(1509966526, 1),

"t" : NumberLong(1)

},

"optimeDate" : ISODate("2017-11-06T11:08:46Z"),

"electionTime" : Timestamp(1509966314, 2),

"electionDate" : ISODate("2017-11-06T11:05:14Z"),

"configVersion" : 3,

"self" : true

},

{

"_id" : 1,

"name" : "server2:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 5936,

"optime" : {

"ts" : Timestamp(1509966526, 1),

"t" : NumberLong(1)

},

"optimeDate" : ISODate("2017-11-06T11:08:46Z"),

"lastHeartbeat" : ISODate("2017-11-06T12:46:13.691Z"),

"lastHeartbeatRecv" : ISODate("2017-11-06T12:46:14.150Z"),

"pingMs" : NumberLong(0),

"syncingTo" : "W2012DEV4:27017",

"configVersion" : 3

},

{

"_id" : 2,

"name" : "server3:27017",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 5847,

"optime" : {

"ts" : Timestamp(1509966526, 1),

"t" : NumberLong(1)

},

"optimeDate" : ISODate("2017-11-06T11:08:46Z"),

"lastHeartbeat" : ISODate("2017-11-06T12:46:14.578Z"),

"lastHeartbeatRecv" : ISODate("2017-11-06T12:46:10.127Z"),

"pingMs" : NumberLong(0),

"configVersion" : 3

}

],

"ok" : 1

}

Legen Sie im Installationverzeichnis der MongoDB (z.B. <Installationspfad>\MongoDB) eine Textdatei key.txt an. Diese Datei dient als Preshared Secret für die MongoDB-Dienste untereinander. Geben Sie in dieser Datei einen schlüsselartigen, zufälligen String aus Buchstaben und Zahlen an (zwischen 6 und 1024 Zeichen), z.B.:

  • w4u5zoawer9wz78raow83zoawze2ri6uazvbuiwer

Verwenden Sie keine Leer- oder Sonderzeichen in dem Schlüssel-String (nur Buchstaben und Zahlen mit 6 bis 1024 Zeichen). Der erstellte Schlüssel-String muss in allen key.txt Dateien auf allen Clusterknoten (server1, server2 und server3) identisch sein.

In der Konfiguration der MongoDB muss die vorstehend erzeugte Schlüsseldatei angegeben und die Authentifizierung eingeschaltet werden.

Fügen Sie am Ende der Konfigurationsdatei mongod.cfg (im Verzeichnis <Installationspfad>\MongoDB) folgende Zeilen ein:

security:

keyFile: <Installationspfad>\MongoDB\key.txt

authorization: enabled

Ersetzen Sie <Installationspfad> durch den tatsächlichen Installationspfad ihrer IQ4docs Installation.

Die mongod.cfg darf keine Leerzeilen oder TABs enthalten (außer ganz am Ende).

Damit die bisher vorgenommenen Einstellungen greifen, müssen die MongoDB-Dienste neu gestartet werden.

Nach der Installation aller Clusterknoten sind noch manuelle Anpassungen durchzuführen.

  • Geben Sie in der LocalService.config des ConfigServices aller Clusterknoten bei MongoDbHost und RabbitMQHost die Hostnamen aller Clusterknoten (mit Komma getrennt) an. Sie finden die Datei im Installationsverzeichnis im Unterverzeichnis ConfigService (z.B. C:\Printsystem 4\ConfigService\LocalService.config).
    • <add key="MongoDbHost" value="server1,server2,server3"/>

    • <add key="RabbitMqHost" value="server1,server2,server3"/>

  • Geben Sie den neuen Clusterknoten im Bereich Server (Cluster-Nodes) im System-Bereich an, siehe System-Bereiche.

Starten Sie nach der Einrichtung alle beteiligten Rechner neu.